1. Field of the Invention
This invention relates generally to a system for increasing productivity in managing, tracking, and using reusable software modules; and more particularly, relates to an object management system having a repository for storing objects wherein ones of the objects are descriptive of a respective software module cataloged by the object management system, and wherein other ones of the objects are system objects describing the manner in which scripted tools that are available for performing various operations on the software modules may be invoked in a manner that is independent of the scripted tool interfaces.
2. Description of the Prior Art
Computer technology is rapidly evolving. This provides a challenge for software developers who have an increasingly difficult time keeping pace with the various adaptations required to allow existing software to meet ever-changing requirements. For example, currently, much work is being done to adapt software applications and data repositories residing on mainframe systems so that these applications may be accessed via web browsers. Alternatively, it may desirable to modify source code designed for operation on Unix platforms so that it is operational on other platforms such as Microsoft Windows NT platforms. Even within a so-called family of computers, where the architecture of the new generation of computers has been designed to maintain a certain degree of compatibility with the prior generation, it is often a major task to adapt computer programs to the new architecture.
In addition to the types of transformations discussed above, an increasing amount of coding effort is being spent on code renovation. This is particularly true with the millennium approaching. Many billions of dollars will be spent world wide adapting software to properly handle dates falling after Dec. 31, 1999 to remedy what has commonly become known as the xe2x80x9cY2K problemxe2x80x9d. Another type of renovation effort is needed to allow software to handle the European Monetary Unit (EMU), or xe2x80x9cEuroxe2x80x9d, which will become the common currency within many European countries within the next few years. Still other types of conversion are necessary when porting software between two machines that do not use the same word sizes. Software modification is further required when porting code to a machine having an expanded addressing space.
Many vendor tools are available to aid users in performing the types of transformation and renovation operations discussed above. Some of these tools may be used to translate an entire code sequence so that the code sequence becomes operational from within a different environment.
Other vendor tools perform the transformation process by making the interfaces of a code sequence available from an external environment, while allowing the body of the code sequence to remain unchanged. These tools produce so-called xe2x80x9cwrappersxe2x80x9d for the code interfaces, which are surrounding layers of code and data structures that hide the original code environment from the calling entity, and that allow the original code sequence to be called from an external environment. In some instances, part, or all, of the wrapper will be ported to the external (calling) system. For example, DGate Ace, which is commercially available from the Unisys Corporation, is a tool that builds a wrapper around the code entry points of enterprise server Open OLTP transaction applications. This wrapper makes the code entry points available to calling programs residing within a Microsoft ActiveX environment.
Various vendor tools are likewise available to perform analysis and renovation functions.
For example, Fulcrum 2000, commercially available from RMC, Ltd., is a tool that performs code analysis operations on a specified code sequence to flag potential Y2K problems. Another similar code analysis tool is described in U.S. Pat. No. 5,488,714 to Skidmore, which is assigned to the assignee of this invention. The Skidmore system performs code analysis on code sequences to produce a listing of recommendations for source code conversion. In the described embodiment, the listing of recommended changes is used to convert code designed for operation within a 16 Megabyte (Mbyte) memory environment to code operational within a 64 Megabyte memory environment.
In addition to vendor tools that are used to perform transformation and renovation operations, other types of tools are commonly used when updating and managing code objects. For example, file transfer utilities are needed to move code objects from platform to platform. Other utilities such as compilers and linkers are needed to generate executables for source code objects that have been modified. Each of these tools may have a unique interface, and unique requirements.
The set of vendor tools which are integrated for use by an object management system will vary from system to system depending on user needs. As mentioned above, many of these tools have unique interfaces that include particular command sets, modes of operation, requirements for operation, and requirements concerning input and output parameter formats. Some of these tools require that some preprocessing or preliminary actions be performed before a given tool may be invoked on a set of software modules. As a simple example, before a linker may be invoked, the code to be linked must first be compiled. Other tools require that data be copied to a particular location within a server before the transformation process on that data may occur. This may be accomplished, for example, by using a program utilizing the File Transfer Protocol (FTP) to copy files from a host system to a location within an external server. Since the user may want to perform a combination of transformation, renovation, and code development processes using multiple tools, the user must become familiar with a variety of tool interfaces. The associated learning curve adds to the time and effort required to perform the task.
Another problem associated with performing transformation, renovation, and code development operations involves identifying the various code and data components that must be submitted to undergo the conversion process. In large complex systems, program calls and data exchanges are made between many re-usable software components. The inter-relationships between these code components are not always obvious. Therefore, when a particular functionality is to be ported from one environment to another, it is often difficult to decide exactly which code and data components must actually undergo some type of transformation to accomplish the task.
What is needed is a comprehensive system which hides the complexities associated with a variety of object management tools, and further hides the particularities of the code interfaces, from the end user so that renovation and transformation operations may be performed more quickly, and with fewer errors.
It is a primary object of the invention to provide an improved object management system;
It is another object of the invention to provide an object management system for supporting transformation, renovation, and code development operations performed by a set of disparate tools;
It is yet another object of the invention to provide an object management system wherein tools for managing, manipulating, and modifying objects are invoked independently of individual tool interfaces;
It is another object of the invention to provide a system for managing, manipulating, and modifying objects using a disparate set of tools by utilizing natural language phrases indicative of the process to be performed on the objects;
It is yet another object of the invention to provide a system for managing, manipulating, and modifying objects using a process-based interface which allows objects to be selected for processing based on natural language descriptions which are independent of the storage structure within which the objects are stored;
It is another object of the invention to provide a system for managing, manipulating, and modifying objects using a process-based interface, wherein the process-based interface is defined using a model;
It is still a further object of the invention to provide a object management system including a disparate tools, each performing one or more operations on selected objects stored within the system, the object management system further for storing a set of rules (protocols) for describing the requirements associated with each of the operations performed by each of the tools;
It is yet another object of the invention to provide an object management system for storing a set of processes, each process being comprised of a set of rules and describing the general manner in which a set of tasks may be performed on a set of objects to accomplish a desired result;
It is yet another object of the invention to provide an object management system for allowing users to select and update any stored process to create a particularized plan designed to perform a specific result on a selected group of one or more stored objects;
It is a further object of the invention to provide an automated interface for allowing the creation of particularized plans, protocols, and processes;
It is a further object of the invention to provide an object management system including a repository capable of storing protocols, processes, and plans as objects;
It is another object of the invention to provide an object management system for supporting transformation operations performed on selected ones of stored objects wherein the transformation steps to be performed may be specified in terms of processes described by natural-language phrases;
It is another object of the invention to provide an object management system for supporting renovation operations performed on selected ones of stored objects wherein the renovation steps to be performed may be specified in terms of processes described by natural-language phrases;
It is a further object of the invention to provide a system for performing multiple transformation and renovation steps on a selected set of objects using a single process invocation;
It is yet another object of the invention to process a selected set of objects using selected functions provided by multiple tools, all invoked using a single process invocation;
It is still another object of the invention to provide an object management system providing for the manual re-execution of stored plans;
It is yet another object of the invention to provide an object management system providing for the automated re-execution of stored plans;
It is a further object of the invention to provide an object management system wherein the impact of performing modifications to code, data, and tool modules is minimized with respect to the protocols, processes, and plans;
It is another object of the invention to provide an object management system that stores interrelationships between protocol, process, and plan objects, wherein the interrelationships provide an efficient means of performing impact analysis when changes occur to any of the objects; and
It is another object of the invention to provide an object management system capable of storing execution history associated with each of the stored plans for tracking the manner in which objects stored in the system have been created, manipulated, and used.
Still other objects and advantages of the present invention will become readily apparent to those skilled in the art from the following detailed description of the preferred embodiment and the drawings, wherein only the preferred embodiment of the invention is shown, simply by way of illustration of the best mode contemplated for carrying out the invention.
The forgoing objects and other objects and advantages are provided in the current invention, which is a process-driven object management system for managing data and code modules. The object management system includes a repository that stores objects, wherein ones of the objects referred to as xe2x80x9cAsset elementsxe2x80x9d each describe a respective code or data module. These objects provide a catalog that inventories the code and data modules being managed by the system. The repository further stores relationships between the objects that model the relationships existing between the code and/or data modules modeled by the respective objects. The objects and object relationships may be viewed by users and analyzed by automated analysis tools to provide insight into the interdependencies existing between the software modules.
The object management system includes a set of tools for performing renovation, transformation, and code development tasks. The current invention provides a process-based interface to this disparate set of vendor tools. This interface is developed using Protocols, Processes, and Plans. Protocols are constructs that each stores a script for invoking a respective scripted tool to execute a particular function. The Protocols are defined in a generic manner such that any software modules that might be provided as input parameters or generated as output parameters of the function invocation are specified as variables to be supplied at execution time.
Processes are constructs that store definitions descriptive of a particular task to be performed. The task to be performed is described using one or more protocols and/or one or more other processes. That is, a process is a grouping of protocols and other processes, wherein the functions described by the protocols and processes will perform a desired task. Processes may further include logical statements written in any scripting language, and which are included to perform error and recovery operations. Like protocols, processes are written in a generic format that identifies a type of software module that can be the target of the task, but does not identify a specific software module or modules on which the task is to be performed.
Processes can be used to develop Plans, wherein a Plan is a developed script that may be executed by a script engine to complete the task described by an associated process. Plans include a designation of the software modules that are to be used as input and output parameters of the task. A Plan may be provided to a script engine for execution either immediately after the plan is created from a process, or on a scheduled basis.
Plans may be created by users having a minimal amount of system knowledge. This is accomplished by an automated Plan development tool that polls the user to select a Process to be developed into a Plan. This polling can be done using natural language expressions stored within the Processes themselves. Furthermore, the user can be polled for the software modules that are to be operated on and/or created by a selected Process. This is accomplished using the Process information indicating the allowable types of software modules that may be associated with the Process. In this manner, a user can initiate the execution of complex operations without understanding the complexities of, or the interrelationships between, tools and tool interfaces. Furthermore, the user need not understand the interdependencies existing between the software modules that are to be the target of the initiated operation.
In the preferred embodiment, the Protocols, Processes, and Plans are each stored as objects in the object management system repository. These objects, which may be referred to as xe2x80x9cSystem elementsxe2x80x9d, are stored in a manner that is similar to the way in which the Asset elements describing the software modules are stored. Furthermore, the associations between Protocols, Processes, and Plans are stored as relationships between the respective objects in a manner that is similar to the way relationships between the software modules are represented.
Representing the Protocols, Processes, and Plans as objects within the object management system has several advantages. Some of the same tools that are used within the system to create, update, manage, and view the Asset elements can be used to perform similar functions on the System elements. The relationships existing between the various System elements allow a user or an automated development tool to readily discover the interdependencies existing between the constructs. This is valuable when performing impact analysis after a modification is made to one of the System elements. Additionally, the repository interface includes automated functions that can be invoked by both the automated Plan development tool and the script engine to simplify Plan development and execution.
In the preferred embodiment, the definition of the System elements is model driven. This means that each of the System elements, as well as the relationships that may exist between the elements, are created using a pre-defined element type or relationship type definition that is also stored within the repository. The model definition both simplifies the system design and makes operation more robust because the various tools in the system can be synchronized with the element and relationship type definitions instead of having to be aware of special-case and particularized element descriptions. Additionally, modifications to the elements can be more readily accomplished because a whole class of element definitions can be modified by making a single change to an element type definition. The type definitions also allow the automated Plan development tool to efficiently query the user for process and Asset element selections.
Another aspect of the current invention involves the recordation of Plan execution status. Plan Execution Record constructs are created after the execution of any Plan. These constructs, which in the preferred embodiment are stored as System elements, record information and status about Plan execution that are useful in documenting the software development process.
Still other objects and advantages of the present invention will become readily apparent to those skilled in the art from the following detailed description of the preferred embodiment and the drawings, wherein only the preferred embodiment of the invention is shown, simply by way of illustration of the best mode contemplated for carrying out the invention. As will be realized, the invention is capable of other and different embodiments, and its several details are capable of modifications in various respects, all without departing from the invention. Accordingly, the drawings and description are to be regarded to the extent of applicable law as illustrative in nature and not as restrictive.